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1.0 



IPLOS Program Management provides the mechanisms through 
which the user may organize and present his programs to the 
system. The three basic constructs of Program Management arei 
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Job 




Job 


J .Single address 1 
1 space 1 
1. Batch submission J 


Job in most 1 
systems 1 










1 or single user 1 
1 terminal session t 






Program 




Task 


1. Separate naming 1 
I context (entry 1 
1 pts - externals) 1 
J. Separate common 1 
i block a 1 1 ocations 1 
1. Separate load 1 


COBOL Run Unit 1 
CYBER Program 1 
CENTURY Program 1 
PL3S Task 1 
MASTER Task 1 
OS/VS Job Step 1 




Procedure 




Subtask 


1 .Separate stack \ 
I frame 1 
1 i 


PL/I Task 1 

CENTURY B2 Task 1 

BURROUGHS Async 1 

Procedure 1 



TABLE 1.0-1 

PROGRAM MANAGEMENT BASIC EXECUTION CONSTRUCTS 

The progression from Job to task to subtask is characterized 
by a.) decreasing amounts of static data, b.) decreasing 
overhead involved in initiation, and c.) increasing amounts of 
automatically shared data. 

Each of these constructs is dealt with in greater detail in 
the ensuing parts of this section. 
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Program Management also provides the mechanisms for 
communications between Joos and between programs in execution. 

For communication between nonsimul taneousi y active Jobs, a 
mailbox file is provided. The mailbox provides a permanent 
repository (i.e., unrelated to the life of a particular Job), for 
messages. This enables Joos to enter the system in arbitrary 
order, at arbitrary times, and to sequence and synchronize their 
subsequent activations. 



the fo I lowing 



For executing Jobs, tasks, or subtasks, 
communication mechanisms are available! 

LNS 

Signals 

Queues 

Events 

Semaphores 

Signature locks 

On conditions 

These mechanisms allow Jobs, tasks, and subtasks to 
synchronize and coordinate themselves with other asynchronous 
activities. These mechanisms and the requests which are used to 
manipulate them are treated in greater detail in ensuing parts of 
this section. 
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1.0 INTRODUCTION 

1.1 REQUIREMENTS AND OBJECTIVES 
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\ TYPE 



\ SCOPE I DATA 



I LIFETIME 



USAGE 



Mailbox J Inter 
i Job 
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local I Intra 
I Job 



LNS 



gl obal I Inter 
I Job 



Event 



I Intra 
i Job 
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Signal I Inter 
I Job 
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Queue 



I Intra 
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I 



Sema- I Intra 
phore I Job 
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S Job 



On Con- J Intra 
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Arbitrary I 
\ 
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Predefined! 
by type I 

I 
I 
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Job 



I System 
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Boolean I 

I 
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Stack, 

Static 



128 bytes I 
I 
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DEQUEUE or 
Overwri te 



Arbitrary I 

I 
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(Job) LNS, 

Stack, 

Static 



Integer 



(Job) LNS, 

Stack, 

Static 



Compare \ 
Swap word I 



Segment 



Condition I Stack 
Register I 
\ 



Job sequencing. 
Communication 
between users 



Symbolic access 
from termina I , 
Passing parameters 
fron user to the 
system 



Synchronization, 
Interrupt control 



I/O requests, 
System Job 
Communications 



Queuing signals, 
passing data 



Synchronizat ion. 
Locking (using 
shared resources) 



Synchron ization 
(Compare Swap) 



Handling execution 
condition. See 
Doc ASL00211. 



TABLE 1.0-2 
PROGRAM MANAGEMENT BASIC COMMUNICATION CONSTRUCTS 
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1.1 REQUIREMENTS AND ORJECTIVES 

The following is a summary of the major requirements and 
objectives that motivate the design of IPLOS Program Management! 

o ANSI standard COBOL (excluding PLC proposal ATG-71001 .111 

Asynchronous Processing Facility) 
ANSI standard FORTRAN 
o Multiprocessing-multiple degrees of sharing and overhead 

to initiate 
o Protection - multiple .subsystem services in the same 

address space 
o Sharing - effective use of a large virtual memory 



1.2 



The following are definitions of terms relevant to 'Program 
Management. 



Address Space 



Binary Obj ect File 



Binding Section 



Binding Segment 



Condition 



Control Point 
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The set of segments addressable in a 
job. Each address is uniquely identified 
by a segment number and a byte number. 

A file containing one or more contiguous 
object modules. All object modules in 
the segment have the same segment 
attributes. 

The ooject environment component used to 
control transfer between rings of 
protection. There is one binding section 
per loaded module. 

A segment containing the binding sections 
of one or more modules loaded into the 
address space of a job. There are 
several binding segments per job. 

A synchronous occurrence of interest to 

the task or subtask in which it 

occurred. The arithmetic faults, such as 
overflow, are examples of conditions. 

The basic execution entity recognized and 

NCR/CDC PRIVATE REV 29 APR 75 



1 
2 
3 

5 
6 
7 
8 
9 
10 
11 
12 
13 
1^ 
15 
16 
17 
18 
19 
20 
21 
22 
23 
Zk 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3^ 
35 
36 
37 
36 
39 
i»0 
^1 
kZ 
k3 
kk 
k5 

ke 

k7 



ADVANCED SYSTEM LABORATORY 
IPLOS GDS - PROGRAM MANAGEMENT 



CHPOeO^ 



1-5 
75/05/21 



1.0 
1.2 



INTRODUCTION 
DEFINITION OF TERMS 



ADVANCED SYSTEM LABORATORY 
IPLOS GDS - PROGRAM MANAGEMENT 



CHPOeO^ 



1-6 
75/05/21 



1.0 
1.2 



INTRODUCTION 
DEFINITION OF TERMS 



Control Point id 



Entry Point 



Event 



Event Control Block 



Externa I 



Gate 



Gate Registration 



Global Key 



Job 



dispatched by the System Monitor. Among 
its contents is the hardware defined 
Exchange Package. 

A system unique identification of a 
control point used as the destination 
address of signals. 

A named externally accessible address in 
a module. The entry points may be in 
either the code section or the working 
storage section of the module. 

An asynchronous occurrence of 
significance to a task or subtask. Task 
completion* tirae* and I/O completion are 
typical examples of events. 

A data structure required to manipulate 
the flow of control via event requests. 
May be in LNS? internal static* or a 
stack. 

A symbol referenced by a module that is 
defined as an entry point in another 
modu le • 

A hardware protected entry point for 
crossing between programs. Protection 
changes can only occur at gates. 
Validation of the right to change can be 
done at the gate. 

The act of making a gate known within a 
Jobf such that subsequent loading will 
link to the protected entry point when 
referenced. 

One of the two keys associated with every 
known segment. Verified on every access 
and 01 call /return sequences. Intended 
as a mechanism for isolating programs 
executing in the same ring of 
protection. Not supported in v 1.0. 

Job is defined in Section 1.0 of Chapter 
h of the OSGDS. 
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Job Gate Table 



Job Stack Table 



Library 



Load Module 



Loader Map 



Loader Symbol Table 



Local Key 



Mailbox 



Object Module 



Procedure 



A table used by Prograu Management to 
register gated entry points on a j ob 
basis. 

A table used by Program Management for 
ring by ring allocation of stacks when a 
control point is created. 

A segment containing procedures and the 
dictionaries required to locate them. 
The procedure dictionary is organized by 
entry point name. All load modules in 
the library have the same segment 
attributes. 

An object module reformatted by OBLIGE 
for residency on a library. Can be a 
single procedure. Structured as directly 
ref erenceable storage* code section 
shareable among users. 

The output of the Loader describing the 
allocations performed for all the 
sections of all the modules in the loaded 

program. 

An internal table built and used by the 
Loader for matching externals and entry 
points. There is a separate Loader 
Symbol Table per loaded program. 

One of the two keys associated with every 
known segment. Verified on every 
access. Always associated with the 
segment and not verified or passed on by 
call/return sequences. 

A file used for communication between two 
users* for example* for Job sequencing. 
May contain messages. 

A single piece of machine executable code 
output from a compiler. Structured as a 
series of records on a file that are 
interpreted every time tie object module 
is processed. 

Code that may be executed serially via 
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1.0 INTRODUCTION 

1.2 DEFINITION OF TERMS 



hardware call instruction or executed 
asynchronously via spawning a subtasK. 

Program A set of object files, set of libraries, 

and an entry point name which specifies a 
static set of procedures organized to 
perform some specific function (e«g«f 
compile COBOL statements). An activation 
of a program is a task. 

Program Control BlocK LNS structure required to construct a 
program by linking external references 
and entry points in a specified order. 
It can be in any LNS segment. 



Queue 

Queue Control Block 

Ring 

Semaphore 

Signal 

Signal Buffer 

Signal Selection List 

Signature Lock 



A collection of data items awaiting 
processing. Standard signals are 
queued. 

A data structure required to manipulate a 
queue via queue requests. May be in LNS, 
internal static, or a stack. 

The fifteen hierarchial levels of 
protection available within a single 
job. Used to protect local monitors and 
services from their users. Capability in 
ring n is always greater than or equal to 
capability in ring n+1. 

A system supported facility to permit 
synchronization among asynchronous 
activities within a Job. It is the most 
primitive such facility supported by the 
system. 

A signal is a short message primarily 
used for inter-job communications in the 
form of requests and responses. 

A system structure used to interface 
signal reception by a control point. 

A system table used to register signal 
selections on a control point basis. 

The ex ternal izat ion of Compare-Swap for 
locking data in shared segments between 
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Subsystem 



Subsystem Services 



Subtask 

Task 

Task Control Block 

Task Monitor 
Task Services 



jobs. 

A Job which provides services to the user 
in the same way as those provided by the 
System Job. It is protected from the 
user, and the Operating System is 
protected from it. 

A set of shared procedures (both code and 
internal static) which provide Subsystem 
services and are directly callable. They 
have • the same clock accounting, 
scheduling and execution characteristics 
as the requestor. The only difference is 
their access rights to data and code. 
They are also protected from Task 
Services, that is, in a different ring. 

Asynchronous execution of a procedure 
within a single task. AM static data 
associated with the tas-^ is associated 
with the subtasks. The subtask' receives 
only a new stack segment as a repository 
for private data. 

Identifiable execution of a program. 

A system LNS data structure required to 
identify a tas< and pass it parameters. 

A collection of shared, nonresident, 
reentrant procedures which monitor and 
provide a formal interface between user 
and system monitor. 

A set of shared procedures (both code and 
internal static) which provide Operating 
System services and are directly 
callable. They have the same clock 
accounting, scheduling and execution 
characteristics as the requestor. The 
only difference is their access rights to 
data and code. 
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2.0 PROGRAM EXECUTION 
2.1.1 JOB 



2.0 ERa&SAa_£JL££IUIiaii 



2.1 EXECUTION CONSTRUCTS 



IPLOS supports three major execution constructs! 

o JOB 

o TASK 

o SUBTASK 



2.1.1 JOB 



The job is the mechanism through which the batch or 
interactive user interfaces to the IPL system. A job consists of 
a Sinalfi segmented address space and all the work performed by 
the job taKes place within that address space. 

The convention of associating a single address space with a 
job is not mandatory, however, the OS project feels that there 
are several factors which make it desirable! 

o It allows natural sharing of information between 
components of the Job - al I information is addressed 
tnrough the same mechanism (i.e., the same segment 
descriptor table) 

o It allows the code which manages the components of a job 
(i.e., program establisher, task establisher, loader) to 
be a part of the same job thereby a.) facilitating the 
component management and b.) isolating it from other jobs 
and the system code responsible for job management. 

It allows large amounts of the system and user provided 
environment that all components of the Job depend upon to 
only be established once for all the components In the job 
(e.g., task monitor, subsystem services, etc.) 

It allows straightforward invocation and parameter passing 
between the aforementioned shared environment and a user 

task. 

NCR/COC PRIVATE REV 30 APR 75 
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There are also several disadvantages to the single job per 
address space relationship! 

o The volatility of comings and goings of programs and data 
within the address space forces the loading of absolutized 
components to be preplanned (i.e., the permanent 
reservation of a segment in every address space). 

Components that are independent of each other and have 
therefore no need to share or communicate are unprotected 
from each other and therefore subject to time dependent 
errors. This may be improved somewhat by utilizing the 
various protection mechanisms available within the the 
address space (.e.g., rings, global or local keys). 



the single 



In spite of these disadvantages, we feel that 
address space per job is the best way to proceed. 



2.1.2 TASK 



A program is the principal way work is organized for the 
user by Program Management. It is the typical unit of loading 
and execution. The program itself is a static entity, that is, 
it is the object files and lioraries which get established and 
linked for each separate execution of the program. Each one of 
those executions is a separate task. 

Each task represents a separate loading and execution 
environment. Any common blocks (i.e., FORTRAN common, PL/I 
static external, COBOL global) declared in the task are 
accessible by any procedure in the task. All entry 
point - external reference matchings with the exception of gate 
linkages are evaluated in the task context. No data is 
automatically shared between tasks in the same job, however, 
since they are in the same address space, sharing segments is 
facilitated. 



2.1.3 SUBTASK 



A procedure is a logically discrete piece of code that is 
the basic component of a program. A procedure may be compiled 
with other procedures to form a single object module? may be 
bound by the library generator with other object modules, or may 
be linked to other discrete object modules at execution time. 
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A task is defined to Program Management with a Task Control 
Block (TCB). The TCB specifies the program to be executed and 
its execution environment. A task is established by Issuing a 
PM^EXECUFE request. Task establishment consists of loading a 
program, and creating a control point with an exchange package 
and stacks for established programs In different rings that will 
be called during the course of execution. The simplest task 
example would be one with an exchange package, a stack for the 
user program, and a stack for the task services program. 

Subsystem Services programs can be established and Included 
in the execution environment. A control point and stacks are 
created by a PM#EXECUTE request but not by a PM#ESTABLISH 
request. Both effect the loading of a specified program. 

2.2.1 LOADING 

A program is defined to Program Management with a Program 
Control Block (PCB) . The PCB specifies a list of object files, a 
list of library files, and an entry point for the program. The 
Loader uses this information to construct an object module 
segment, a working storage segment, and a binding segment. 

First the Loader builds the object module segment from the 
list of object files, if specified. An object file is generated 
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by a compiler and may contain one pr more object modules that 
represent code in a nonexecutable form. The format is detailed 
in Chapter 11 of the OSGDS. For each object module, the Loader 
creates an executable code section In the object module segment, 
a working storage section and a binding section. 
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From the list of object files, every object module, 

referenced or not, is loaded resulting in Loader Symbol Table 

entries, a working storage section, and a binding section. Only 
referenced load modules are loaded. 

Library segments may be shared by jobs. Programs using the 
same object file get separate object module segments built by the 
Loader. 

The search order used by the Loader when resolving an 
external reference is as followsi 
o Loader Symbol Table 

o Dictionary on each library in the order of the list, 
o Job Gate Table 



2.2.2 TABLES 



2.2.2.1 



The program control block (PCB) is an LNS structure used to 
define a program to the system. It has the following Itemsi 

o Primary entry point - the name of the entry point at which 
to begin execution of the program. An alternate 
starting entry point can be specified in a task 
control block. 
Binary object file list - the LNS name of a list of binary 
object files, each of which containing one or more 
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contiguous object modules. 

Library list - the LNS name of a list of libraries* Each 
library segment contains one or more load modules and 
dictionaries organized by entry point name that are 
used to locate procedures. Ail load modules in a 
library have the same segment attributes* 

Size - the initial worKing set size for the program* It 
is the number of page frames needed by any execution 
of the program when first brought into core by the 
Running Job Monitor. 

Ring - the ring of execution for the program* If 
specified 9 it must be within the execution bracKet 
for all the files and segments specified in the PCS* 

Termination entry point - an optional field specifying an 
entry point name for a termination procedure* If 
present, the termination procedure will be called by 
the system during the orderly process of task 
termination. Parameters will be passed indicating a 
normal or abnormal termination* 



2.2.2.2 



ol Bipgk 



The task control block (TCB) is an LNS str 
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fol lowing i temst 
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generated for a loader map. 
Abort - options indicating the kind of dump 

abort. 
Exit - the type of exit (normal, abnormal) t 

task via the PM#EXIT request. 
Code- an integer completion code specified 

request by this task. 
Message - a completion message up to 

specified on the PM#EXIT request by thi 
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o EPCB - pointer to the Established Program Control Block 
for this task. Placed here by the Establisher* 



2.2.2.3 £sia&Ustigd. Prgflram ^ntrpl 6l9CK 



The established program c ontro I block (EPCB) is a structure 
internal to Program Management and is used to define the loaded 
environment for a program* The EPCB can be the result of either 
a PM#EXECUTE request or a PM#ESTABLISH request and has the 
following itemst 

o How established- indicates' estab I ished by PMiEXECUTE or 
by PM#ESTABLISH. 

- the LNS locator of the task control block specified 
on either request* 
- the LNS locator of the program control block* 

the LNS locator of the Job control block for the | ob 
in which the program is established* This field is 
used to obtain Job Gate Table and Job Stack Table 
entries for any further linking and stack allocation 
in this Job* 
Ring - the ring in which the program 
o Loader symool table - pointer to the 

for this program* 
o Binary object file list - the same list specified in the 



TCB 



PCB 
JCB 



is to be executed* 
loader symbol table 



PCB but in a format more convenient for use by the 

loader* 
Library list - the same list specified in the PCB but in a 

format more convenient for use by the loader. 
Thread - the EPCBs are threaded together on a Job basis* 

The starting point is in the JCB* 
Keys - the global and local key (not supported in V 1*0)* 
Event - pointer to the event control block of the task 

completion event for the task as specified on the 

PM#EXECUTE request* 
Control point - the control point id for the task. 
Dependencies - task dependency threads for future use* 
LNS search list - pointer to the LNS search list for this 

established program* 



2*2*2.^ Job. Gate, lablg 



The Job Gate Table (JGT) is a structure internal to Program 
Management and is used to register gated entry points on a Job 
basis. The JGT is searched by the Loader when resolving external 
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references. An entry point is registered in the JGT during the 
loading of a module that possesses the gate attribute. All the 
entry points of such a module are registered as gates. 

Gate is the mechanism used to satisfy the requirement of 
protecting one program from another by alloMing entry to the 
protected code at defined points. Not only does the Loader put a 
gated entry point in the JGT but also marks it in the binding 
section so the hardware can enforce the protection. The user 
cannot write a binding section. 



2.2.2.5 Job Stack Table 



The Job Stack Table (JST) is a structure internal to Program 
Management and is used to allocate stacks when a control point is 
created. It is a job local array of integers indicating the 
number of stacks to allocate on a ring-by-ring basis. When a Job 
is created, some minimum set of Job and execution tables are 
built. The JST is included in this job template specifying stack 
allocation for Task Services. Using the PM#ESTABLISH request 
will change the JST for the specified program establishment 
ring. 

2.2.3 TASK ESTABLISHMENT EXAMPLE 

The purpose of the following example is to show structures 
visible to the user that make up the execution environment for 
his program. The example starts at the point execution is asked 
for via SCL» which in turn issues the requests 

PM#EX£CUTE (taskf event, status) 

taskt the LNS descriptor of "USER.TCB" obtained by SOL via 
the LNS#ENTRY request. 

event: not used in this example. 

statusi request status returned to SCL. 

Figure 2.2-1 shows the relationship of LNS structures 
declared prior to issuing PM#EXECUTE. For these structures, the 
diagram includes only those LNS fields necessary to the example. 

o "USER_TCB"J local LNS name of the Task Control Block 
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specifying the program to execute and the parameters 
retrievable by that program. 

o "USER_PCB"s local LNS name of the Prograu Control Block 
defining the program via a list of object files and a list 
of I ibrary segments. 

o "USER_OBJ_LIST"t local LNS name of list of object files 

generated by prior compilation. The object modules on 

these files will be converted to code sections in the 
object module segment. 

o "USER_LIB_LIST"t local LNS name of the list of library 
segments to be used to search in the order listed for 
unresolved external references. 

o "0BJ_FILE_1" and "0BJ_FILE_2" I local LNS names of the File 
Control Blocks describing the object files to be loaded. 
The example has each file containing one module, A and B 
respectively. 

o "USER_LIBRARY"l local LNS name of a File Control Block 
describing the library file of the user. Only the 
referenced modules of this library will be loaded. The 
user can convert object files to library segments by using 
the library generator, OBLIGE. 

o "COBOL_RUN_TIME"t global LNS name of a File Control Block 
describing the library segment of COBOL run time 
routines. This library segment is generated by the 
installation and is shared by users. 

Figure 2.2-2 shows the user segments created through program 
loading for the PM#EXECUTE request. Note that working storage 
sections and binding sections are created for every object module 
but not every load module. Only the user stack segment is 
shown. There would also be a stack segment allocated via the JST 
for Task Services. 

Figure 2.2-3 shows additions to user segments resulting from 
the request: 

PM#LOAD (name, type, pointer, status) 

name: name of an entry point in load module D on the user 
I ibrary file. 

type: type of pointer to be used in a reference to the 
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module. 

pointeri the returned pointer after loading. 

status! returned request status. 

The load module D does not have any externals causing the 
loading of any other modules. Had it any» those load modules 
contained the matching entry points would have been loaded by 
PMfLOAD as wel I. 
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Figure 2.2-1 
LNS STRUCTURES 
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Figure 2. 2-2 
USER SEGMENTS 
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Figure 2.2-3 
ADDITIONAL SEGMENT SECTIONS 
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2.2.^ SUBTASK ESTABLISHMENT 



2.2.4.1 SubtasK Qontro 



The subtask control bl ocK is an LNS structuret the 
declaration of which causes the allocation and initialization of 
a control point and the allocation of stacks according to the Job 
Stack Table. It has the following items« 

o Control point - the control point id tyoically passed by 
Task Services in the body of a signal being sent to a 
System Task in the System Job. That System Task then 
has a return signal address to be used when sending a 
resDonse. 
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There 
eventual ly 



are several levels of documentation that will 
exist for interfacing to program execution! 
Command Language statements 
Control Language macros 
Requests 
Calls 



Documentation for calls will detail three parameters in SWLt 
o Request code 
o Returned request status 
o Request b lock 



This documentation will be 
definitions have been compiled. 



provided as soon as request 



Control Language macros may not necessarily be one-to-one 
with the calls. There may be sone calls not visible in the 
Control Language. Likewise, there may be some Contr9 I Language 
macros not externalized through the Command Language. 

The Control Language macros for program execution are as 
followsi (To be supplied). 

Request documentation is simply a prose description of a 
function performed and the parameters supplied by the requestor* 
Requests are one-to-one with calls. The program execution 
requests are followst 

PM#EXECUT£ (task, event, status) 

PM#EXIT (type, code, message) 

PM#TERMINATE (task, status) 

PM#SPAWN (entry, parameters, subtask, event, status) 

PM#LOAD (name, type, pointer, status) 

PMiENTRY (name, gate, segment, type, pointer, status) 

PM#REINITIALIZE (name, status) 

PM#ESTABLISH (task, status) 

PM#DIS£STABLISH (task, status) 



2.3.1 PM#EXECUTE 



This request is used to load a program and create a task to 
asynchronously execute that program. 
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2.0 PROGRAM EXECUTION 
2.3.tf PM#SPAWN 



PM#EXECUT£ (tasK, event* status) 

task: the LNS descriptor of a previously declared task 
control block used by the requestor to identify and 
control task execution. The task control block Identifies 
the program control block of the program to be loaded and 
executed. 

eventi optional parameter that is a pointer to an event 
control block to be associated with task completion. If 
specif ied» Program Management will cause the event when 
task completion is detected. 

statuss returned request status. 



2.3.2 PM#EXIT 

This request is used to indicate task completion. 

PM#EXIT (type» code* message) 

typei indicates the type of exit being taken* normal or 
abnormal. The exit_tyoe is put in the task control block 
by the PMiEXIT request processor. 

codeX a programmer defined integer put in the task control 
block by the PM#EXIT request processor. 

message 1 a programmer defined message up to 31 characters put 
in the task control block by the PM#EXIT request 
processor . 

2.3.3 PM#TERMINATE 

This request is used by a task to terminate another task. 

PM#TERMINATE (task, status) 

tasKt the LNS descriptor of the task control block of the 
task to be terminated. The TCB must be one used for a 
previous PM#EXECUTE request. 

status: returned request status. 
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2.3.^ PM#SPAWN 



This request is used to start an asynchronous execution of a 
subtask within a task. 

PM#SPAWN (entry, parameters* subtask, status) 

entry: pointer to procedure at which to start asynchronous 
execution. 

parameters! pointer to argument list for the procedure. 

subtask: the LNS descriptor of a previously declared subtask 
control block, which resulted in allocations of a control 
point and stacks. 

status: returned request status. 



2.3.5 PM#LOAD 

This request is used to load a procedure not yet referenced 
in a program. 

PM#LOAD (name, type, pointer, status) 

name: entry point name. 



type: the type of pointer to be returned. Can specify return 
of a kb bit pointer, a code base pointer, or a code 
base-binding section pair. 



pointer: returned 
wanted. 



pointer according to specified type 
status: returned request status. 



2.3.6 PM#ENTRY 



This request is used to retrieve a pointer to be used in a 
call to 3 specified entry point. The module containing the entry 
point must have been previously loaded. The order of search for 
the entry point is the same for loading (a Loader Symbol Table 
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2.0 PROGRAM EXECUTION 
2.3.8 PM#ESTABLISH 



and then the Job Gate Table). 

PM#ENTRY (name* gate» segment* type» pointer* status) 

namet entry point name. 

gate* optional parameter indicating search should be only on 
the Job Gate Tab le. 

segment! optional parameter indicating the segment which 
dictates the LST to start the search. Segment numbers in 
a Job are unique per establishment of a program. 

typei type of pointer to be returned. Can specify return of 
a '♦8 bit pointer* a code base pointer* or a code 
base-bindiig section pair. 

pointer! returned pointer according to type. 

status! returned request status. 

2.3.7 PM#REINITIALIZE 

The purpose of this request is to provide COBOL an Operating 
System function necessary to satisfy their implementation of the 
ANSI standard CANCEL statement. This assumes the implementation 
of their CALL statement would use our PM#LOAD request. We do not 
currently know exactly what is required of the Operating System 
to satisfy any requirement imposed by a CANCEL implementation. 

PM#REINITIALIZE (name, status) 

name! entry point name. 

status! returned request status. 

2. 3.8 PM#ESTABLISH 



This request is used to establish a program in the address 
space of a job. The primary purpose of the request is to 
establish subsystem services on a job basis. 

PM#ESTABLISH (tasK, status) 
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task! the LNS descriptor* of a previously declared task 
control block used py the requestor to identify and 
control the loading of a program. The task control block 
identifies the program control block of the program to be 
loaded. 

status! returned request status. 



2.3.9 PMiDISESTABLISH 



This request is used to remove an established program from 
the address space of the job. 

PM#OISESTABLISH (task* status) 

task! the LNS descriptor of the task control block describing 
the program that was established. 

status! returned request status. 
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3.0 LOGICAL NAME SPACE MANAGEMENT 
3,0.1 DESIGN OBJECTIVES 



3.0 LOGIQftL NAM^ SPACE 



This document is the GDS for the Logical Name Space manager 
for IPL/OS. 

The functions described are the basic capabilities of the 
subsystem. As the OS requirements for LNS services become better 
defined) more sophisticated functions will be bjilt using these 
basic capabilities. 
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3.0.1 DESIGN OBJECTIVES 



The design objectives of the Logical Name Space manager are 
as fol loMs. 

• To provide a generalized technique for the mapping of 
names to data. 

• To provide a symbol table handler for System Command 
Language. 

• To apply structuring methods to dynamic OS data 
compatible with SHL data representation for OS code and SCL for 
user manipulation* (i.e. recordst arrays^ etc.) 

• To retain certain attributes of data to ai low generic 
requests that may operate on several types of data or resources* 

• To provide a degree of data protection and privacy by a 
hierarcical blocK structure of data segments while allowing the 
explicit sharing of data when required. 
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Ail internal LNS information uses relocatable addressing 
enabling a segment to be established at any virtual address while 
preserving previously defined information* 

During Job initiation the system allocates an LNS segment 
list and initializes it as follows* 



LNStfGLOBAL 



system global segment 
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3.0 LOGICAL NAME SPACE MANAGEMENT 
3.1.1 LNS DESCRIPTORS 



LNS#LOCAL 



other segnents 
most local segment 



Eacn entry has an internal entry descriptor. These internal 
descriptors are managed in sei/eral chains per segment with a name 
hashing algorithm randomly assigning an entry to a chain. The 
entry search strategy includes a percolating of the internal 
descriptor chain which results in the chain being ordered by most 
recent use. Item chains are handled in the same manner. 

An entry and its internal descriptor form the primary node 
of a data structure through which the user can descend to any 
level • 
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3.1.1 LNS DESCRIPTORS 



Each entry or item in the LNS has an internal LNS descriptor 
associated with it which is NOT accessable to the user. The 
definition of this internal descriptor is as follows. 



type_desc = RECORD 

desc_typeJ (entryt item)* "type 
locKf BOOLEAN, "internal synchro 
chain! REL ~type_desc, "chain to 
namel STRING (31) OF CHAR, "name 
hashs 0..255, "hash value of nam 
excis STRING (31) OF CHAR, "excl 
non_exclt 0.. 65565, "non-exclusi 
data_tyoet 0..max_type, "subscri 
data_lent 0..max_len, "string or 
data_dim: 0..max_dim, "dimension 
data I REL '*type_data, "location 
ex_attrl SET OF 1..6^, "extrinsi 
RECENO, 



of descriptor" 
nization lock" 

next descriptor" 

of entry or item" 
e" 

usive lock key" 
ve I ock count" 
pt to LNS#TYPE tabl« 

set length" 

of array variable" 
of data" 
c attribjtes" 



A complex type is described by an array of internal field 
descriptors. This array exists only once in the global segnent 
regardless of fhe number of occurences of the complex type. The 
definition of the internal field descriptor is as follows. 

type_field_desc = ARRAY [♦] OF RECORD 

namet STRING (31) of CHAR, "name of field" 
hashi 0..255, "hash value of name" 

data_typet 0..max_type, "subscript to LNS#TYPE table" 
data_leni 0..max_len, "string or set length" 
data_dim« 0..max_dim, "dimension of array variable" 
data! REL ~type_data, "location of field in record" 
ex_attrl SET OF 1. . 6^, "extrinsic attributes" 
RECEND, 

Several of the LNS requests require or return a descriptor. 
This descriptor resides in the users memory and is fully 
accessable. The definition of this descriptor is as follows. 
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type_user_desc = RECORD 

data.type: 0..max_type, "subscript to LNS#TYPE table" 

data_lent 0..max_len» "string or set length" 

data.dimi 0..max_dim, "dimension of array variable" 

data_size: 0. . max_si ze, "size of data in cells" 

excit BOOLEAN, "exclusive locK on" 

non_exci: BOOLEAN, "non-exclusive lock(s) on" 

datat ~type_data, "location of data" 

desci ''type_desc, "location of internal descriptor" 

ex_attr: SET OF l-.G**, "extrinsic attribjtes" 

RECENO, 
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3.1.2 LNS DATA TYPES 



LNS data types fall into two classes; simple and complex. A 
simple type or a complex type may be an element of a complex 
type. The currently defined simple types are as follows. 



UNKNOWN 

INTEGER 

REAL 

BOOLEAN 

STRING 

SET 

POINTER 

CELL 

ALIAS 

CHAIN 



undefined type (undec larabi e) 

integer variable 

real variable 

boolean variab le 

.character string variable 

set variable 

pointer variable 

eel I variabi e 

LNS a I ias name 

LNS item chain 



The following additional subsets of INTEGER will be included 
when their IPL/SHL representations are defined. 



SUBRANGE 
ORDINAL 



(x, y, z, p, LNS) 



The following SHL representation att-^ibutes are not 
supported at this stage of the LNS design. 

PACKED 
CRAMMED 

The currently defined complex types are as follows. 



SCLiTOKEN 

SCL#OPERATOR 

SCL#FUNCTION 

SCLfCOMMAND 

SCL#MACRO 



SCL token 
SCL operator 
SCL function 
SCL command 
SCL macro 
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3.1.3 LNS STRUCTURES 



By the use of cataloged internal descriptors of complex 
types and chained itemst arbitrarily complex structures may be 
assembled. 



3 • 1 • 3 . 1 General Example s 



Examples of the commands to build the structures shown are 
included using Command Language syntax for clarity. The 
following symbols are used in the diagrams of these structures. 



entry name 

f iel d name 

item name 

LNS internal descriptor 

chain linkage 

data 



The following structure is built tor scalar 
variables. 

eeeeeeee 
dddddddd... 

I 

t.>xxxxxxxx 

Examples 

lns#declare name* integer 

The following structure is built for numeric arrays. 

eeeeeeee 
dddddddd... 
t 

t .>xxxxxxxx 
xxxxxxxx 
xxxxxxxx 
xxxxxxxx 

Ex amp I et 

lns#declare nametreal fdim^^ 



numeric 
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The following structure is built for scalar string 
variables. 

eeeeeeee 
dddddddd... 

s 

s. >xx XXX XXX xxxxxxxx xxxxxxxx xxxxxxxx 

Ex amp I el 

lns#declare naie«string 

The following structure is built for string arrays. 

eeeeeeee 
dddddddd... 
: 

t. >XX X XX XXXX XXX XXXX XX xxxxxxxx XXX XXX 
XX XXXXXXX XXX XXXX XX xxxxxxxx XX xxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

XX XXXXXXXXXX XXXX XXXXXX XXXX XXX XXX 

Examples 

Insideclare name,string»32»^ 
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3.1.3.1 General Examples 



The following structure is built for complex types. 

eeeeeeee 

dddddddd >fff f f fff 

t ...dddddddd 

t • >xxxxxxxx<. t ffffffff 
XXX xxxxx< . . . .dddddddd 

. . .cccccccc<. . ffffffff 

: I ..dddddddd 

: 

t.>iiiiiiii ..>iiiiiiii ..>iiiiilii 
cccccccc.t cccccccc.i cccccccc 

...dddddddd ...dddddddd ...dddddddd 

t t I 

s.>xxxxxxxx t. >xxxxxxxx i.>xxxxxxxx 

Examples 

lns#record record_name »3 
I ns#f ield record_name» fie I d_at integer 
I ns#f ield record_name« fie ld_b,real 
I ns#f ie Id record_namet fie I d_c» chain 
I ns#dec lare structure «type=record_name 
I ns#insert structure. f iel d_Cf itera_a 
I ns# insert structure, f iel d_c» item_b 
lns#insert structure . f iel d_c» item_c 
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As illustrated below* all combinations of items and 
are permitted. 



eeeeeeee 

dddddddd . .. >f f f f f f f f 

t ...dddddddd 

s . >XXXXXXXX<. I ffffffff 

xxxxxxxx<... .dddddddd 
. ••cccccccc<... ffffffff 
t xxxxxxxx<. t. dddddddd 
I t ffffffff 

t t.. -.dddddddd 

t 
x.>iiiiiiii ..>iiiiiiii 

cccccccc.i cccccccc, 
...dddddddd ...dddddddd 
t t 

I S. >xxxxxxxx 

1 

I ..>fff f f f ff 

s ...dddddddd 

i.>xxxxxxxx<.t ffffffff 
xxxxxxxx<... .dddddddd. > 
xxxxxxxx<. I 
xxxxxxxx I I ffffffff<, 
s t. dddddddd 
t ffffffff 
t.. .dddddddd 



fields 



..>iiiiiiii 
I cccccccc 
...dddddddd 

s 

I.>CCCCCCCC. . 

t 
iiiiiiii<.s 
cccccccc 
dddddddd,. • • 

t 
s xxxxxxxx<.t 



Example: 

I ns#record 
Insffield s 
Insffield s 
I ns# record 
i ns#f ield s 
lns#field 3 
I ns#record 
ins#field r 
Insffield r 
Insffield r 
Insffield r 
I nsfdeclare 
I nsf insert 
I nsf insert 
I nsf insert 
I nsf insert 



Ir 



If 



Ir 



subrecord_b»2 

ubrecord_b, fie ld_afreal 

ubrecord.bt f iel d_b, dim=2 

suDrecord_a »2 

ubrecord_at fie ld_a» integer 

uorecord_a»f ield_b »type=subr ecord_b 

record_name»4 

ecord_name» f iel d_a» integer 

ecord_naroetf ie ld_b,real 

ecord_name»f iel d_c , chain 

ecord_name» f ie Id_dtstringt8 

name»type=record_name 
name. f iel d_c» item_a» type=subrecord_a 
name. f ield_c »i tem_b 
name, fie ld_c» item__c, t ype=chain 
name, f iel d_c. i tem_c i tem_a»rea I 
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3.1.3.2 SCL #TOKfe N gXamp.lfi 

SWL Dafinltlon 

TYPE 

lns#desc = RECORD 

data_typei 0..max_type» 
data_len: 0..max_len, 
data_diml 0..max_dim, 
data_sizex 0..max_sizef 
excl I BOOLEAN, 
non_excl: BOOLEAN, 
datai ~type_data, 
desci "^type.desc, 
ex.attrt SET OF 1..6^, 
RECEND, 

scl #string = RECORD, 
Ihit 1..256, 
rhii 0..255, 

buffi STRING (255) OF CHAR, 
RECEND, 

sc l#toKen = RECORD 
typi INTEGER, 
desc: lns#desc, 
ivi INTEGER, 
rvt REAL, 
svi scl#string, 
RECEND? 

LNS Definition 

lns#record I ns#desc,9, (dec lare» insert ) , I ns#103 
lns#field lns#desc,.data_type 
lns#field Insidesc, data_len 
lns#field lns#desc, data_dim 
lns#field lns#desc,data_size 
lr»s#field lns#desc,excl ,bool ean 
Ins^field lns#desc,non_excl , boolean 
lns#field I ns#desc, data, pointer 
lns#field lns#desc, desc , pointer 
lns#f iel d lns#desc,ex_attr,set,6^ 

lns#record sc I #string,3 , (dec lare , insert ) , I ns#10 3 
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lns#field scl#string,lhi 
lns#field scl #string,rhi 
lns#field sc I #string,buf f ,string, 255 

lns#record scl#toKen,5 

lns#field scl #token,typ 

lns#f ield sc I #toKen, desc, Insfdesc 

lns#field scl#token,iv 

lns#field scl#token,rv,real 

lns#f ield scl #token»sv,scl #string 
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3.1.^ TYPE CONTROLLED "OWN CODE" PROCEDURES 
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These procedures are defined at the time the 
descriptor is catalogued by the LNS#RECORD request, 
loader is called with the named procedure to supply 
procedure pointer variable (^PROC) in the LNS#TYPE 
procedure is called by the specified LNS reque 
variao le or a field of a variable of the sped 
referenced. The trap procedure is invoked prior to 
the LNS request with the exception of LNS 
LNS#INSERT. These two requests call the pr 
completing their respective functions. A trap 
issue LNS requests. However* recursion and Lnte 
are possible if the logic of the trap is defective. 
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Two examples of possible uses of these procedures are to 
initialize variables when declared or inserted or to monitor 
changes via get and put by the user to tables currently in use by 
the system. A third exsrmple would be the implicit declaration of 
associated variables or insertion of items into a chain field. 

A set of procedures named in the form LNS#<status code> are 
supplied in the LNS library. These procedures function as own 
code trap routines and return the status record indicated by 
their name. For example LNS#103 returns a status of "invalid 
type" and may be used to prevent declaration of a complex type 
intended only for use as a field of another complex type and 
never as a variable on its own. This is illustrated in the 
SCL#TOKEN example. 
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3.1.5 EXTRINSIC ATTRIBUTES 

In addition to the normal LNS intrinsic attributes* the LNS 
system will retain 6^ user defined extrinsic attributes for any 
element. These attributes have no meaning to tne LNS system but 
may be assigned and queried by the user. 

Attributes 33 to 6^ are reserved for operating system use 
(i.e. SCL decoding attributes) while attributes 1 to 32 may be 
manipulated by the end user (i.e. problem program). 

Currently reserved attributes are: 

33..<fO system command language 

3.2 LNS REQUESTS 

The following requests are available for the manibulation of 

LNS. 
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3,2.1 LNS#ATTACH 



The purpose of the LNSfATTACH request is to add a new 
segment to the LNS segment list as the most local segment. 

LNS#ATTACH (segment, old, status) 

segment! The segment parameter specifies a string containing 
the name of a segment currently known to the Job (i.e. 
mapped in) . 

old: The old parameter specifies a boolean variable. If the 
value of the variable is true, the LMS data currently 
in the segment will be accessable. If the variable is 
false, tne segment will be initialized as empty. 

status: The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error conditions". 
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3.2.2 LNS#0£TACH 



The purpose of the LNS#DETACH request is to remove a segment 
from the LNS segment list. 



LNS#DETACH (segment, status) 

segment: The segment parameter specifies a string containing 
the name of the segment to be detached. Omission of 
this parameter (indicated by a blank string) will cause 
the most local segment to be detached. 

status: The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error conditions". 
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3.2.3 LNS#DECLARE 



The purpose 
entry in the LNS . 



of the LNS#OECLARE request is to declare an 



LNS#DECLARE (segment, entry, type, length, dim, status) 

segmenti The segment parameter specifies a string containing 
the name of the segment in which the entry is to be 
declared. Omission of the segment parameter (indicated 
by a blank string) will cause the entry to be declared 
in the most local segment. 

entry: The entry parameter specifies a string containing the 
name of the entry being declared. 

typel The type parameter specifies a string containing the 
type of the entry being declared. Omission of the type 
parameter (indicated by a blanK string) will cause an 
entry of type INTEGER to be declared. The valid LNS 
types are those described under "data types" or any 
complex type previously defined by LNSiRECORD and 
LNS#FIELD. 

length: The length parameter is only meaningful when 
declaring string or set variables. For strings the 
parameter specifies an integer containing the number of 
bytes to be allocated for the string. For set 
variaoles the integer contains the number of elements 
in the set. Omission of the length parameter 
(indicated by a 0) will cause a default of 32 to be 
assumed. 

dim: The dim parameter specifies an integer containing the 
dimension of the entry being declared. Omission of the 
dim parameter (indicated by a 0) will cause a default 
of 1 to be assumed. 

status: The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error conditions". 
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3.2.^ LNS#REMOVE 



The purpose of the LNS#REMOVE request is to remove an entry 
from the LNS. 



LNSfREMOVE (segment, entry, status) 

segment: The segment parameter specifies a string containing 
the name of the segment which is to be searched for the 
entry. Omission of the segment parameter (indicated by 
a blanK string) will cause each segment whose name 
appears in the LNS segment list to be searched. 

entry: The entry parameter specifies a string containing the 
name of the entry which is to be deleted. 

status: The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error conditions". 
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3.2.5 LNS#ENTRY 

The purpose of the LNS#ENTRY request is to get the 
descriptor of an LNS entry given the name of the entry. 

LNS#ENTRY (segment, entry, subscr, desc, status) 

segmenti The segment parameter specifies a string containing 
the name of the segment which is to be searched for the 
entry. Omission of the segment parameter (indicated by 
a blank string) will cause each segment whose name 
appears in the LNS segment list to be searched. 

entryl The entry parameter speci fies a string containing the 
name of the entry whose descriptor is being sought. 

subscr: The subscr parameter specifies an integer containing 
the subscript to be used when the entry is an array. 
Omission of the subscr parameter (indicated by a 0) 
will cause a descriptor of the entire array to be 
returned. 

desct The desc parameter specifies a record into which a 
descriptor is to be returned. 

status: The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error cor^dit ions". 
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3.2.6 LNS#NEXT 



The purpose of the LNS#NEXT request is to get the descriptor 
of a field or item given the descriptor of the enclosing entry, 
item or field. 



LNS#NEXT (input_desc, name, subscr, output_desc, status) 

input_desc: The input_desc parameter specifies the name of a 
record containing a. descriptor of the enclosing entry, 
field or item. 

name: The name parameter specifies a string containing the 
name of the field or item whose descriptor is being 
sought. 

subscr: The subscr parameter specifies an integer containing 
the subscript to be used when the field or item is an 
array. Omission of the subscr parameter (indicated by 
a 0) will cause a descriptor of the er^tire array to be 
returned. 

output_desc: The output_desc parameter specifies a record 
into which the descriptor of the field is to be 
placed • 

status: The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error conditions". 
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3.2.7 LNS#SLICE 



The purpose of the LNS#SLICE request is to get the 
descriptor of an element of an array given the descriptor of the 
array. 



LNS#SLICE (input_desc, subscr, output_desc, status) 

input_desct The input_desc parameter specifies, a record 
containing the descriptor of the array to be sliced. 

subscrt The subscr parameter specifies an integer containing 
the subscript of the desired element. 

output_descJ The output_desc parameter specifies a record 
into which the descriptor of the element is to be 
Placed. 

statusi The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error conditions". 
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3.2.8 LN3#GR0W 



The purpose of the LNS#GROW request is to grow the dimension 
of an LNS entry or item. 



LNSiGROW (desc, incr, status) 

descJ The desc parameter specifies a record containing a 
descriptor of the entry or item whose dimension is to 
be grown. 

inert The incr parameter specifies an integer containing the 
increment by which the dimension of the entry is to be 
grown. Omission of the incr parameter (indicated by a 
0) will cause a default of 1 to be assjmed. 

status! The status parameter specifies a variable ipto which 
the status record is to be placed. The status codes 
returned are descrioed under "error conditions". 
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3.2.9 LNS#LOCK 



The purpose of the LNS#LOCK request is to lock an LNS entry 
or item. The locKing operation has no effect on other requests 
except other LNS#LOCKs, LNS#UNLOCK, LNS#REMOVE and LNS#DELETE. 



LNS#LOCK (desc, excl , Key, status) 

descx The desc parameter specifies a record containing a 
descriptor of the entry or item to be locKed. 

excl : The excl parameter specifies a boolean variable. if 
the value of the variable is true» access to the entry 
will be exclusive. If the value is false* access will 
be non-exclusive. 

Keyi The key parameter specifies a string of 31 characters 
in which a unique name will be returned when the access 
requested was exclusive. If non-exclusive access was 
requested, the contents are unchanged. 

statusi The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error conditions". 
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3.2.10 LNSfUNLOCK 



The purpose of the LNS#UNLOCK request is to jnlock an LNS 
entry or item. 



LNS#UNLOCK (desc, key, status) 

descJ The desc parameter specifies a record containing a 
descriptor of the entry or item to be unlocked. 

keyt The key parameter specifies a string containing the 
string returned by the LNS#LOCK request when the entry 
was locked for exclusive access. If the entry is being 
unlocked from non-exclusive access the key parameter is 
ignored. 

statust The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are descrioed under "error conditions". 
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3.2.11 LNS//INSERT 



The purpose of 
item into a chain. 



the LNS#INSERT request is to insert a new 



LNS#INSERT (desc, item, type* length, dim, status) 

desci The desc parameter specifies a record containing a 
descriptor of the entry, field or item within which the 
item is to be allocated. 



item: The item parameter specifies a string 
name of the item to be allocated. 



containing the 



typel The type parameter specifies a string containing the 
type of the item being inserted. Omission of the type 
parameter (indicated by a blank string) Will cause an 
item of type INTEGER to be inserted. The valid LNS 
types are those described under "data types" or any 
complex type previously defined by LNS#RECORO and 
LNS#FIELD. 

length! The length paran»ter is only meaningful when 
inserting string or set items. For strings the 
parameter specifies an integer containing the number of 
bytes to be allocated for the string. For set items 
the integer contains the number of elements in the 
set. Omission of the length parameter (indicated by a 
0) will cause a default of 32 to be assumed. 

dim? The dim parameter specifies an integer containing the 
dimension of the item being inserted. Omission of the 
dim parameter (indicated by a 0) will cause a default 
of 1 to be assumed. 

statusJ The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error conditions". 



NOTEi The trap to an "own code" 
request is determined by 
i nserted. 



procedure by the LNSilNSERT 
the data type of the item being 
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3.2.12 LNS#DELETE 

The purpose of the LNS#OELETE request is to delete an item 
from a chain. 

LNS#OELETE (desc, item, status) 

desci The desc parameter specifies a record containing a 
descriptor of the entry, field or item which is to be 
searched for the item. 

itemx The item parameter specifies a string containing the 
name of the item to be deleted. 

status! The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error conditions"; 

NOTEl The trap to an "own code" procedure by the LNS#DELETE 
request is determined by the data type of the item being 
deleted. 
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3.2.13 LNS#GET 



The purpose of the LNS#GET request is to get a value from 
the LNS. 



LNS//GET (desc, buffer, .status) 

desc: The desc parameter specifies a record containing a 
descriptor of the entry, field or item whose value is 
being sought. 

buffer: The buffer parameter specifies a buffer into which 
the value is to be placed. 

statust The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error conditions". 
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3. 2. lit LNS#PUT 



The purpose of the LNS#PUT request is to put a value into 
the LNS. 



LNStfPUT (desc, buffer, status) 

descx The desc parameter specifies a record containing a 
descriptor of the entry, field or item whose value is 
to be updated* 

bufferi The buffer parameter specifies the buffer containing 
the new va I ue. 

status* The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error conditions". 



1 
2 
3 

5 
6 
7 
8 
9 
10 
11 
12 
13 
1^ 
15 
16 
17 
18 
19 
20 
21 
22 
23 
2*f 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3k 
35 
36 
37 
38 
39 
^0 
^1 
kZ 
kZ 
kk 
kS 
kb 
k7 
kB 



NCR/CDC PRIVATE REV 20 MAY 75 



NCR/CDC PRIVATE REV 20 MAY 75 



AD\/AMC£0 SYSTEM LABORATORY 
IPLOS GOS - PROGRAM MANAGEMENT 



CHPOeO't 



3-29 
75/05/21 



3,0 LOGICAL NAME SPACE MANAGEMENT 
3.2.15 LNS#SETXA 



3.2.15 LNS#SETXA 



urpose of the LNS#5ETXA request is to set the extrinsic 
of an entry or item. Permission to alter attributes 



The pur 

attributes _. _.. , _. _. . ,. 

33. .6^ is verified by the OS^CHECK procedure. 



LNS#S£TXA (desct attr, status) 

descJ The desc parameter specifies a record containing a 
descriptor of the entry or item whose extrinsic 
attributes are to be set. 

attrJ The attr parameter specifies a set of 1..6^ containing 
the attributes to be changed. This set will be "xored" 
to the current set of attributes resulting in the 
symetric difference of the two sets. In other wordst 
the presence of any attribute in this parameter causes 
the attribute to be "toggled" in the LNS internal 
descriptor. 

status! The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are described under "error conditions". 



1 
2 
3 

5 
6 
7 
8 
9 
10 
11 
12 
13 
Itf 
15 
16 
17 
18 
19 
20 
21 
22 
23 
2k 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3k 
35 
36 
37 
38 
39 
^0 
kl 
kZ 
kZ 
kk 
kS 
kb 
k7 
kB 



ADVANCED SYSTEM LABORATORY 
CPLOS GOS - PROGRAM MANAGEMENT 



CHP060't 



3-30 
75/05/21 



3.0 LOGICAL NAME SPACE MANAGEMENT 
3.3 PRIVILEGED REQUESTS 



3.3 PgiyiLFGEn R EQUES TS 

The following requests are subject to restrictions such as 
Operating System only or SE# OP use. When any of these requests 
are issued permission is verified by the OS#CHECK procedure. 



1 

2 

3 

k 

5 

6 

7 

8 

9 

10 

11 

12 

13 

1^ 

15 

16 

17 

18 

19 

20 

21 

22 

23 

Zk 

25 

26 

27 

28 

29 

30 

31 

32 

33 

Zk 

35 

36 

37 

38 

39 

kO 

kl 

kZ 

kZ 

kk 

kS 

kb 

k7 

k8 



NCR/CDC PRIVATE REV 20 MAY 75 



NCR/CDC PRIVATE REV 20 MAY 75 



ADVANCED SYSTEM LABORATORY 
IPLOS GDS - PROGRAH MANAGEMENT 



CHPOeo^ 



3-31 
75/05/21 



3.0 LOGICAL NAME SPACE MANAGEMENT 
3. 3,1 LNS#RECORD 



ADVANCED SYSTEM LABORATORY 
IPLOS GDS - PROGRAM MANAGEMENT 



CHPOeO^ 



3-32 
75/05/21 



3.0 LOGICAL NAME SPACE MANAGEMENT 
3.3.1 LNS#RECORD 



3.3.1 LNS#RECORD 



The purpose of the LNS#RECORD request is to define a new 
complex type to the system. The type definition is always 
gl obal . 



LNS#RECORD (record» fields, traps* procedure, status) 

record: The record parameter specifies a string containing 
the name of the complex type to be defined. 

fields! The fields parameter specifies an ir^teger containing 
the maximum number of fields to exist in the complex 
type. 

traps! The traps parameter specifies an ordered set of 
requests for which an "own code" procedure is to be 
invoked for this type. If this parameter is omitted 
(indicated by an empty set) no traps will occur. The 
positional significance of each request in the set is 
as foil ows. 

LNS#DECLARE 1 

LNS#R£MOVE 2 

LNS#ENTRY..... • 3 

LNS#NEXT •••••••..^ 

LNS«SLICE 5 

LNS#GROW 6 

LNS#LOCK 7 

LNS#UNLOCK 8 

LNS#INSERT«... 9 

LNS#OELE?E ..••••10 

LNS#GET. 11 

LNS#PUT./ .,..12 

LNS#SETXA .....13 

procedure! The procedure parameter specifies a string 
containing the name of the "own code" procedure to be 
invoked as indicated by the traps parameter. The 
procedure named must reside in a library currently 
known to the lob. An error in this parameter will 
result in a status being returned from the loader 
rather than from LNS. If this parameter is omitted 
(indicated by a blank string) no traps will occur. 

status! The status parameter specifies a variable into which 
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the status record is to be placed. The status 
returned are described under "error conditions". 



codes 
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3.3.2 LNS#FIELD 



The purpose of the LNS#FIELO request is to define a field of 
previously defined complex type. 



LNS^FIELD (record, field, type, I en , dim, attr, status) 

record: The record parameter specifies a string containing 
the name of the complex type of which this field is to 

be a member. 

field: The field parameter specifies a string containing the 
name of the field to be defined. This name will become 
the name of the first currently undefined field of the 
complex type. 

type: The type parameter specifies a string containing the 
type of the field to be defined. Omission of the type 
parameter (indicated by a blank string) will cause a 
field of type INTEGER to be defined. The valid LNS 
types are those described under "data types" or any 
complex type previously defined by LNS#RECORO and 
LNS#FIELO. 

length: The length parameter is only meaningful when 
defining string o'* set fields. Far strings the 
parameter specifies an integer containing the number of 
bytes to be allocated for the string. For set fields 
the integer contains the number of elements in the 
set. Omission of the length parameter (indicated by a 
0) will cause a default of 32 to be assumed. 

dim: The dim parameter specifies an integer containing the 
dimension of the field being defined. Omission of the 
dim parameter (indicated by a 0) will cause a default 
of 1 t o be assumed. 

attr: The attr parameter specifies a set of 1..6^ containing 

the extrinsic attributes to be associated with the 

field. Note that tne LNS#SETXA request may not be used 
on field descriptors, 

status: The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are descrioed under "error conditions". 
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3.3.3 LNS#SEGLOCK 

The purpose of the LNS#SEGLOCK request is to perform a 
non-exclusive locK on a segment in order to prevent an LNSiDETACH 
request from being performed. 

LNS#SEGLOCK (segment, status) 

segment: The segment parameter specifies a string containing 
the name of the LNS segment to be locKed. 

status: The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are descrioed under "error conditions". 
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Z.3.k LNS#SEGUNLOCK 



The purpose of the LNS#SEGUNLOCK request is to unlock an LNS 
segment* allowing an LNS#DETACH to be performed. 



LNS#SEGUNLOCK (segment, status) 

segment! The segment parameter specifies a string containing 
the name of the LNS segment to be unlocked. 

status: The status parameter specifies a variable into which 
the status record is to be placed. The status codes 
returned are descrioed under "error conditions". 



3.^ ESEOS^CfllinillQblS 



Error conditions are represented by status information 
returned by each LNS request. The status information may be 
passed to the systen message generator for further expansion and 
logging. 
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LN 000 normal completion 



Parameter errors 



8 LN 101 
8 LN 102 
8 LN 103 
8 LN 10^ 
8 LN 10 5 
8 LN 106 
8 LN 108 
8 LN 109 
8 LN 10 A 

Access errors 

8 LN 201 
8 LN 20 2 
8 LN 2 03 
8 LN 20^ 
8 LN 205 
8 LN 206 
8 LN 207 
8 LN 208 
8 LN 20 9 



invalid segment name 
invalid element name 
inval id type 
invalid length 
invalid dimension 
inval id increment 
inval id key 
inval id subscript 
invalid descriptor 



denied access 

segment exists 

segment does not exist 

entry exists 

entry does not exist 

field exists 

field does not exist 

item exists 

item does not exist 



Functional errors 

8 LN 301 entry already locked 

8 LN 302 entry not locked 

8 LM 303 segment locked by system 

8 LN 30^ element not a chain 

8 LN 305 element not a structure 

8 LN 306 element too large 

8 LN 307 segment not locked 



Internal errors 
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no memory for LNS internal descriptor 

no memory for data 

maximum number of fields exceeded 

maximum number of segments exceeded 

maximum number of types exceeded 

feature not yet supported 

disaster 



1 
2 
3 
k 
5 
6 
7 
8 
9 
10 
11 
12 
13 
Ik 
15 
16 
17 
18 
19 
20 
21 
22 
23 
Zh 
25 
26 
27 
26 
29 
30 
31 
32 
33 
3t» 
35 
36 
37 
38 
39 
40 
k± 
kZ 
kZ 
kk 
kS 
ke> 
k7 



NCR/CDC PRIVATE REV 20 MAY 75 



NCR/COC PRIVATE REV 20 MAY 75 



ADVANCEO SYSTEM LABORATORY 
IPLOS GUS - PROGRAM MANAGEMENT 



CHPOeO^ 



3-37 
75/05/21 



ADVANCED SYSTEM LABORATORY 
IPLOS GDS - PROGRAM MANAGEMENT 



CHPOeOif 



3-38 
75/05/21 



3.0 LOGICAL NAME SPACE MANAGEMENT 
3.i+.2 ERROR CODES BY REQUEST 
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^.1 EVENTS 

Events are system supported facilities which permit 
synchronization and interrupt control for asynchronous activities 
within a Job. An evenf is represented by an event control block 
in storage and several system requests to manipulate the control 
DiocK. An event control blocK may be either an LNS variable or a 
structure in the job data base (internal static* stack* etc.). 

The event control block contains the following information! 
o Condition state (caused* cleared) 
o Action state (enabled, disabled) 
o Action (attached procedure* waited) 

The condition state indicates the current condition of the 
event* caused or cleared. The action state* enabled or disabled* 
directs the system to either immediately effect the specified 
actioi or delay the action. The action can be the invoking of an 
attached procedure* or it can be continuing the execution of an 
asynchronous activity in the Job that has been waiting for the 
causation of this event. The action may also be a combination of 
both for one or several control points in a Job. 
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An interrupt procedure can be attached to an event by using 
the P.^#ATTACH_PROCEDURE request. When an event to which an 
interrupt procedure has been attached does occur* the result will 
be the serial invocation of the attached procedure using the same 

NCR/CDC PRIVATE REV 30 APR 75 
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point as the requestor of the PM#ATTACH_PROCEDURE 



processing 
disabled until enabled by the 



If the action state of the event to which the procedure is 
attached is 'disabled'* the invocation of the orocedure wil I be 
delayed until the event is enabled. Event occurrence 
for a particular event remains 
PM#ENABLE_EVENT request. 

The PM//DISABLE_EVENT request prevents the invocation of any 
and all procedures attached to a particular event. A procedure 
can be attached to more than one event. More than one procedure 
can be attached to one event. 
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^♦.1.1 



EVENT REQUESTS 



The event requests provided by Program Management are as 
fo I I ows : 

PM#AT1ACH_PR0CEDUR£ (procedure, event, status) 
PM#CAUSE_EVENT (event, status) 
PM#CAUSE_CLEAR_EVENT (event, status) 
PMi?CL£AR_£VENT (event, status) 

PM#DETACH_PROCEDURE (procedure, event, status) 
PM#DISABLE_£VENT (eventl, ..., eventM, status) 
PM#ENABLE_EVENT (eventl, ,.., eventM, status) 
PM#STATUS_EVENT (event, condition_st ate , act ion^stat e, 

waited, attached_interrupt_procedure, status) 
PM#WAIT_EVENT (eventl, ..., eventM, position, status) 
PM#WAir_CL£AR_£VENT (eventl, ..., eventM, position, status) 



^.1.1.1 PM#ATTA gH PR9Ct;PURE 

This request establishes an association of an interrupt 
procedure with an event. 

PM#ATTACH_PROCEDURE (procedure, event, status) 

procedure: pointer to the procedure to be invoked when the 
event occurs. 

events pointer to event control block. 

status* returned request status. 

^.1.1.2 PMi£AUS£_i^£liI 

This request sets the specifiad event to caused. If the 
event is in the cleared state when this request is made, the 
system oerforms the action, if any, as specified in the event 
control olock. If the event is in the caused state already when 
this request is made, the system does not perform any specified 
action and informs the requestor via the returned request 
status. Performing the action includes the execution of all 
attached procedures. 

PM#CAUSE_EVENT (event, status) 

NCR/CDC PRIVATE REV 30 APR 75 
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event! pointer to event control block, 
status* returned request status. 

^.1.1.3 PM/^pAUSE CLEAR EVENT 



This requests performs the action, if any, as specified in 
the event control block and returns to the requestor with the 
event in the cleared state. If the event is in the caused state 
already when this request is made, the system does not perform 
any specified action and informs the requestor via the returned 
requests status. Performing the action includes t^e execution of 
all attached procedures. 

PM#CAUSE_CLEAR_EVENT (event, status) 

event* pointer to event control block. 

status* returned request status. 



^.1.1.^ PM<^CLEAR_£V.ENI 

This request sets the condition state of an event to 
cl eared. 

PH#CLEAR_£VENT (event, status) 

event* pointer to an eve^t control block. 

status* returned request status. 



^.1.1.5 PM#P 



pCEDURE 



This request removes the association of an interrupt 
procedure with an event. The requestor must be the same as the 
PM#ATTACH requestor. 

PM#DETACH_PROCEDURE (procedure, event, status) 

procedure* pointer to procedure to no longer be associated 
with the specified event control block. 
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eventJ pointer to event control blocK. 
status* returned request status. 

it. 1.1. 6 aMiaiMfiLL_£V.£fiI 

This request disables ev/ent occurrence processing for an 
event or events. It sets the action state of a specified event 
to disabled. 

PM#OISABLE_EVENT (eventl, ...» eventM, status) 

eventt pointer to an event control blocK. 

statusi returned request status. 



^♦.1.1.7 £M#i 



LE £VEliL 



This request enables event occurrence processing for an 
event or events. It sets the action of a specified event to 
enabled. 

PM#EMABLE_£VENT (eventl, ...» eventM, status) 

eventt pointer to an event control blocK. 

statusi returned request status. 

4.1.1.8 PM^STATUS EVENT 



This request returns the status of an event. 

PM#STATUS_EVENT (event, condi tion_state , act ion_stat e, 

waited, attached_interrupt_procedure, status) 

events pointer to event control block. 

condition_statei returned state indicating caused or 
c leared. 

action_state 1 returned state indicating enabled or 

disab led . 
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waited! returned indication if there are any control points 
in the Job waiting for* this event to be caused. 

attached_interrupt_procedurel returned indication if there 
are any interrupt procedures that are attached to this 
event. 

status t returned request status. 



4.1.1.9 PM//WAIT E VENT 



This request suspends the execution of a control point until 
one or all of a specified number of events has occurred. 

PM#WAIT_EVENT (eventl, ..., eventM, position, status) 

events pointer to an event control block. 

position! if specified, one event occurrence will satisify 
the wait and its position (1-M) will be returned. If not 
specified, all the events must occur to satisfy the 
wait. 

statusi returned request status. 

The system will default a time limit so a 'control point will 
not remain suspended waiting for something that will not occur. 
Elaosed default time limit will be reflected in the returned 
request status. 

While a control point is suspended waiting on an event, 
other events can occur. These are saved until the wait is 
satisfied. Then they are processed in the order of their 
occurrence including the event or events that satisfied the 
wait. Processing event occurrences includes invoking any 
attached interr^jpt procedures. 

The PM#WAIT_EVENT request processor does not alter the 
condition of an event before returning to the reqjestor. 

More than one control point in a Job may wait on an event, 
in which case all are suspended until the condition state of the 
specified event is caused. 

If a task is suspended waiting on an event and there occurs 
another event to which an innei — ring interrupt procedure has been 
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attached, the system will allow the control point to execute the 
interrupt procedure and then be suspended again. 



'♦.l.i.lO PMiMAIL_£LEAS_E.V.£NL 



This request suspends the execution of a control point until 
one or all of a specified number of events has occurred. It is 
the same as the PM#WA IT_E VENT request except that it returns to 
the reqjestor with the condition state of the wait satisfying 
event or events as cleared. 



PM#WAIT_CLEAR_EVENT (eventl. 



eventMy position, status) 



event: pointer to event control blocK. 

position! if specified, one event occurrence will satisfy the 
wait and its position (1-M) will be returned. If not 
specified, all the events must occur to satisfy the 
wait. 

status: returned request status. 

The system will default a time limit so a control point will 
not remain suspended waiting for something that Hill not occur. 
Elapsed default time limit will be reflected in the returned 
request status. 

If a control point is suspended waiting or^ an event and 
there occurs another event to which an inner-ring interrupt 
subprogram has been attached, the system will allow the control 
point to execute that interrupt suDprogram and then be suspended 
again. 

While a control point is suspended waiting on an event, 
other events can occur. These are saved until the wait is 
satisfied. Then they are processed in the order of their 
occurrence including the event or events tiat satisfied the 
wait. Processing event occurrences includes invoking any 
attached interrupt procedures. 

More than one control point may wait on ai event, in which 
case all are suspended until the condition state specified event 

is caused. 
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k.Z _SI£N^LS 



Signals are short messages that are used for inter-Job 
communications usually in the form of requests and responses. 
For example, system code in a User Job can send a signal to the 
System Job to request some specific service. The body of the 
signal would contain the request. It may also contain the 
identification of an associated event control block for an event 
to be caused when a response is received. 

A signal may be associated with a queue via the 
PM#SELECT_5IGNAL request. In this case Program Management would: 

1) out the signal on a queue using the PM#ENQUEUE request 

2) cause the queue-associated event, if any, as noted in the 
queue control block. 

The signal can be removed from the queue by using the PM#DEQUEUE 
request. 

When a signal is received by the destination control point, 
control first goes to a general signal handler and then is routed 
to signal-own-code based on the type of signal. For example, say 
I/O is a type of signal. Then every I/O signal received by a job 
could be processed by an I/O signal module to do whatever is 
particular for an I/O signal. 



The types of signals and the information 
signal are detailed in Chapter 9 of OSGOS. 



^.2.1 SIGNAL SELECTION 



contained in 



The Signal Selection List (SSL) is a structure internal to 
Program Management and is used to register signal selections on a 
control point basis. The PM#SELECT_SIGNAL request associates a 
signal with a queue by creating an entry in the SSL. The Task 
Monitor Signal Handler uses the SSL to queue signals. The 
PM#DESELECT_SIGNAL request removes an entry from the SSL. 
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tf.2.2 SIGNAL REQUESTS 



The signal requests provided by Program Management are as 
to I I ows: 

PM#S£NO_SIGNAL (signal, statjs) 
PM#SELtiCT_SIGNAL (name, queue, status) 
PM#DESELECT_SIGNAL (name, status) 
PM#STATUS_SIGNAL (signal, queue, status) 
PM#DISAaL£_SIGNALS (status) 
PM#ENABLE_SIGNALS (status) 



^.2.2.1 PM/^SEND SIGNAL 

This request sends a signal from one job to another job* 
PM#S£ND_SIGNAL (signal, status) 
signals pointer to the signal to be sent, 
status? returned request status. 

^.2.2.2 PM^^S^LgCI-SISiJAj. 

This request associates a signal with a queue. More than 
one signal may be associated with one queue, bJt not multiple 
queues for a signal. 

PM#SELECT_SIGNAL (name, queue, status) 

name: the signal type and id in the header of the signal 
expected to be received. 

queuei pointer to the queje control blocK to be used by 
Program Management to queue the signal so it will not be 
lost. 

status: returned request status. 
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^.2.2.3 PM»DES.ELECT SXQNAL 



This request breaks the association of a signal with a 

queue. Further receptions of the specified signal will not 

result in those signals being items on the previously specified 
qjeue. 

PM#DESELtCT_SIGNAL (name, status) 

name: the type and id of the signal as specified in a 
previous PM#SELECT_SIG.NAL request. 

status: returned request status. 



^.2.2.^ P M^ASTATU S SIGNAL 



This request provides a way to determine if a particular 
signal has arrived. This is meaningful for the case of more than 
one signal associated with a queue. It can be determined if 
anything is on the queue by using the PM#ST ATUS_QUEUE request. 
It can be determined if a particular signal is on a queue by 
using the PM#STATUS_SIGNAL request. 

PM#STATUS_SIGNAL (signal, queue, status) 

name: type and id of a signal as previously specified in a 
PM#SELECT_SIGNAL request. 

queue: returned pointer to queue control block, if any, as 
specified on a previous PM#SEL£CT_SIGNAL request. 

status: returned request status. 



^.2.2.5 



IGNALS 



This request is used to prevent loss of control due to 
interruption tor signal processing for the requesting control 
point. This request does not prevent hardware interruptions. 

PM#DISABLE_SIGNALS (status) 

status: returned request status 
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^.2.2.6 PMiiLMaL£-ai£ML^ 



This request is used to enable signal processing after a 
previous PM#DISABLE_SIGNALS request. 

PM#ENA8LE_SIGNALS (status) 

statust returned request status. 

^♦.2.2.7 PM/gPENTITY 

This request is used to obtain the executio'> identity of the 
requestor. The execution identity may be the control point id, 
the task control block, the program control block, or the Job 
control block. 

PM#IDENTITY (to be supplied) 
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_£U£JiiLS 



The queuing mechanism provided by Program Management is 
designed to allow the sending, storing, and retrieving of 
arbitrary data structures between asynchronous activities within 
a Job. The queuing facility will be used, for example, by the 
Signal mechanism to pass standard signals to the interested 
control points. An event may be associated with a queue so that 
an enqueue request on the queue would effect causation of the 
event. It is the responsibility of the owner of the QCB to put 
in the pointer to an associated ECB. 

A queue is defined by a queue control block somewhere in the 
address space of the Job. It can be an LNS structure or 
somewhere in the job data base (stack, internal static, etc.) 
The format of a queue control block is shown belowt 



TYPE 



QUEUE_CONTROL_BLOCK = RECORD 
NUMBER_QUEUEDt SEMAPHORE; 
ASSOCIATED_EVENTl '*EVENT_CONTROL_BLOCK , 
CHAIN_STARTJ ^QUEUE^ITEM, 
CHA INTEND! ~QUEUE_ITEM, 
STORAGE_METHODX (To Be Supplied) 

recend; 

E 
QUEUE.ITEM = RECORD 

QUEUE^THREADI ~QUtU£_ITEM, 
OATA_LOCATIONI ""SEQUENCE, 
RECEND. 



The fields in the QUEUE, 
described below: 



:ONTROL_BLOCK and QUEUE_ITEM are 
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NUMB£R_QUEUEO» This semaphore should have an initial value 
of zero. It indicates the number of items currently on 
the queue. Adding an item to the queue will do a 
SIGNAL_SEMAPHORE on this semaphore and getting an item 
from the queue will do a PM#WAIT_SEHAPHORE on this 
semaphore. 

ASS0CIATE0_EVENT: If the 'pointer is other than NIL it 
references an event control block which will be placed in 
the caused state whenever there are items on the queue 
and the cleared state whenever the queue is empty. 

CHAIN_START: Pointer to the first item on the queue. 
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CHAIN_ENDJ Pointer to the last item on the queue* 

ST0RAG£_METH0D: will indicate in some way where storage is 
to be acquired for new queue items. 

aUEUE_THREAD: Thread of items on the queue. 

DA1A_L0CATI0N: Pointer to the data represented by the 

QUhUE^ITEM. 

The actions performed by the queue request processors are 
described in the following decision tablet 



+ + 

OPERATION I ENQUEUE I DEQUEUE 
. I + J ^ 

NUMBER OF ITEMS ON QUEUE I I >0 I J >0 
I 4- J 4. I 4. J + 

ASSO:iATED EVENT lYINIYINIYINIYJN 
4- + + + + + + + 

Add item to queue IXIXIXIXJ I I I 

TaKe item from queue I I I I I I I X I X 

Suspend requesting process I I I I I X t X I 1 

PM#CAUSE_£VENT I X I J I I I I I 

PMtfCLEAR EVENT 5 I I J J I » * I 



♦ if initial value is one. 
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k.S.l 



QUEUE REQUESTS 



The queue requests provided by Program Management are as 
f ol lows! . 

PM^ENQUEUE ( queue t item, status) 
PM^DEQUEUE (queue, item, status) 
PM#STATUS_QJEU£ (queue, status) 



*♦. 3.1.1 PMffENQUE UE 



The PM#ENQUEUE request adds a queue item to a queue and 
activates one process if there is one suspended on the queue. 

PM#ENQUEUE (queue, item, status) 

queue: pointer to the queue control blocK which defines the 
particular queue. 

itemi pointer to the queue item which is to be added to the 

queue. 

status: returned request status. 
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^.3.1.2 PM tfDEOgE UE 



The PM#DEQUEUE request removes an item from a queue and 
returns the location of the item to the requestor. If the queue 
is empty at the time of the request, the requestor is suspended. 

PM#DEQUEUE (queue, item, status) 

queue: pointer to the queue control block which defines the 
particular queue. 

item: returned pointer to item data. The queue item is no 
longer on the queue. 

status: returned request status. 
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4.3.1.3 PM^^STATUS QUEUE 

The PM#STATUS_QUEUE request provides a way to determine if 
there are any items on the specified queue. 

PM#STATUS_QUEU£ (queue, status) 

queue* pointer to the queue control blocK that defines the 

queue. 

status: Indicates whether or not there are any items on the 
queue. 
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^.^ SEMAPHORES 



Semaphores are system supported facilities which permit 
communication and synchronization among asynchronous activities 
within a job. A semaphore is represented by a semaphore control 
block somewhere in storage and two system requests to manipulate 
the control block. A semaphore is the most primitive facility 
supported by the operating, system for synchronization and 
serialization of asynchronous activities. Semaphores are 
utilized by various system routines to serialize themselves and 
in the implementation of Locks and Queues. 

A semaphore may be either an LNS variable or a structure in 
the Job data base (internal static, stack, etc.) The format is 
as shown belowt 



TYPE 



SEMAPHORE = RECORD 

VALUEJ INTEGER, 

CHAIN: ~CONTROL_POINT, 
RECENO; 



VAR 



any_semaphore: semaphore 

The states of a semaphore are shown in the following table: 



1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
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4,0 PROGRAM COMMUNICATIONS 
4.4.1.2 PM#WAIT_SEMAPHORE 



REQUESTED OPERATION J WAIT J SIGNAL 

I 4- *■ I ♦ 4- 

INITIAL CONTENTS OF I J J I I I 
•\/ALUf (V) I <0 I =0 J >0 J <0 I =0 J >0 
4- +-- +- -♦ -+ + 

Resultant contents of J V-l \ V-1 I V-1 I V*-l I V^- 1 I V*l 

'value' (V) III III 

Add request process I II I I I 

to chain and suspend I X I X I I I J 

Remove first process I I I I I I 

from thread and activate I I I I X I I 

Process immediately I I I I I I 

continues I I I X I X I X I X 



For a description of the properties of semaphores and some 
examples of their uses? see section titled Program Management 
Notes. 



4.4.1 SEMAPHORE REQUESTS 

The semaphore requests provided by Program Management are as 
fol lows* 



PM#SIGNAL_SEMAPHORE (semaphore, status) 
PM#WAIT_SEMAPHORE (semaphore, status) 



4.4.1.1 PmSI&NAL_SEMAPHpSE. 

This request increments the 'value' of a semaphore by one. 

If the resultant value is less than or equal to zero, the process 

which nas been waiting for the semaphore the longest is 
activated. 

PM//SIGMAL_SEMAPHORE (semaphore, status) 

semaphore: poiiter to a structure of type semaphore 

status: returned request status. 

NCR/CDC PRIVATE REV 30 APR 75 
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4.4.1.2 PMffWAIT SEMAPHORE 

This request decrements the 'value' of a semaphore by one. 
If the resultant value is less than zero, the requesting process 
is suspended. 

PM#WAIT_SEMAPHORE (semaphore, status) 

semaohorei pointer to a structure of type semaphore 

status! returned request status. 



4.4.2 



INTRA-JOB LOCKS 



LocKs as such are not directly supported by the operating 
system as primitive requests since their function can be whol ly 
replaced by semaphores. The simple two state I ocK is described 
in Oenning's article in the section titled Program Management 
Notes. 

A more flexible locK mechanism is proposed by the CODASYL 
Programming Language Committee Proposal ATG-71001. 11. See the 
section titled Program Management Notes. 



4.4.3 



INTER- JOB SYNCHRONIZATION 



The semaphore and lock mechanisms described above are for 
synchronization of asynchronous activities within a Job. There 
are two mechanisms which permit synchronization and communication 
between Jobs. One is the Signal facility described in 4.2. The 
other is the Compare and Swap hardware instruction which may be 
used on memory locations which are shared between Jobs* The 
Compare and Swap is externalized by two requests referencing a 
signature lock. The two coordinating jobs must be sharing a 
segment with an agreed upon word in that segment designated as 
the signature lock. 



4.4.3.1 ^iaoaty r e_L2£j<-Begij e§t s 



The signature lock requests provided by Program Management 
are as foil ows: 
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AO\/ANCEO SYSTEM LABORATORY CHP060^ 

75/05/21 
IPLOS GUS - PROGRAM MANAGEMENT 

^♦.0 PROGRAM COMMUNICATIONS 
k,k»3,l Siqnature Lock Requests 

PM#SIGN_LOCK (lock, status) 1 

PM#UNSIGN_LOCK (lock, status) 2 

3 
^.^.3.1.1 PM/^$IGN LOC K k 

5 
This request is used to sign a signature lock with the 6 

Control Point id of the requestor. The request is rejected if 7 

the requesting control point already has anything locked via 8 

PM#SIGN_LOCK. Otherwise the request disables signal processing, 9 

does a- compare swap on the signature lock word. If the compare 10 
swap is successful, returns leaving the Control Point id in the 11 
signature lock word. If not successful, enables signal 12 
processing and cycles. 13 

Ik 
PM#SIGN_LOCK (lock, status) 15 

16 

locki pointer to the signature lock word in the shared 17 

segment. 18 

19 
statusJ returned request status. 20 

21 
^. if .3. 1.2 PM#UNS IGN LOCK 22 

23 

This request is used to unsign a signature lock by writing Zk 

it with zeroes. Rejects if the requesting control point does not 25 

have it locked. 26 

27 
PM#UNSIGN_LOCK (lock, status) 28 

29 

lockJ pointer to the signature lock word in the shared 30 

segment. 31 

32 
status: returned request status. 33 

Zk 

35 

k.5 ON!_£QiiaiIIflfclS 36 

37 

38 

To be suppi ied. 39 

kO 
kl 
kZ 
kZ 
kk 
k5 
kb 
k7 
k% 

NCR/COC PRIVATE REV 02 AUG 7k 



5-1 
ADVANCED SYSTEM LABORATORY CHP0 60i» 

75/05/21 
IPLOS GUS - PROGRAM MANAGEMENT 

5.0 PROGRAM MAINTENANCE 



5.0 —PRQJiSAM .HflLlNI£iiM££ 1 

2 
3 
k 
5 
6 
7 
1 o Be SuDPl led 8 

9 
10 
11 
12 
13 
1^ 
15 
16 
17 
18 
19 
20 
21 
22 
23 
2^ 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3^ 
35 
36 
37 
38 
39 
^0 
kl 
kZ 
kZ 
kt* 
kS 
kb 
1^1 
1*6 



NCR/CDC PRIVATE REV 26 MAR 75 



ADVANCED SYSTEM LABORATORY 
IPLOS GjS - PROGRAM MANAGEMENT 

6.0 PROGRAM MANAGEMENT NOTES 



6-1 
75/05/21 



ADVANCED SYSTEM LABORATORY 
IPLOS GDS - PROGRAM MANAGEMENT 



CHP060^ 



6-2 
75/05/21 



6.0 PROGRAM MANAGEMENT NOTES 

6.1 COBOL LOCK NOTES 



6.0 PSQGgAM_MANA&LM£liT NOT£S 



6.1 COBOL LOCK NOTES 



A flexible locK mechanism is proposed by the CODASYL 
Programming Language Committee Proposal ATG-71001.11. The lock 
defined there has four possible states and three operations 
defined on it as detailed in the following diagrami 



1 REQUESTED 
I OPERATION 



I INITIAL STATE 



I Resul tant 
I state 

! 

J Suspend 
! requesting 

• process 
! 

I Activate 

• suspended 
I process 

I if any 

I 

} Request error 

I 

I Process 

\ immediately 

\ continues 



UNLOCK 



I LOCK FOR 
I SHARED USE 



UILIMIEIUILIMIE 



U I L 
J 

I 



LOCK FOR 
EXCLUSIVE USE 



U I L I M I E 



X I X I IX 
+ + <• + + + + 



The states correspond to: 

U = unlocked. 

L = locked for shared use by one process. 

M = locked for shared use by multiple processes. 
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E = locked for exclusive use. 

The following sample coding demonstrates how this fairly 
complex lock mechanism could oe implemented by a run time support 
system or macros using the semaphore mechanism. However» this 
code example does not include the COBOL ATG "AT LOCKED' immediate 
return option. 

"Definition of a lock structure" 

TYPE 

cobol_lock = record 

shareo_count i integer 

exclusive^lock : semaphore, 

shareo_<ey i semaphore, 

exclusiv£_key : semaphore, 
recend; 

"Semaphore used to serialize lock/unlock procedures" 

LOCK_CONTROL : SEMAPHORE 1= CI, nIL] ; 

"Unlock procedure used for both shared and" 
"exclusive locks" 

PROC COBOL_UNLOCK (REF I: COBOL_LOCK); 

WAIT (LOCK.CONTROL) ; 

IF I.EXCLUSIVE_LOCK.VALUE LT 1 THEN 

"If exclusively locked" 

SIGNAL (I.SHARED_KEY) ; 

SIGNAL (I.EXCLUSIVE_LOCK) ; 
ELSE 

"LOCKED FOR SHARED USE" 

I.SHARED^COUNT 1= I. SHARED^COU NT-i; 

IF I.SHAREO_COUNT EQ THEN 

"activate waiters for exclusive lock" 

signal (i.exclusive_key); 
ifend; 
ifend; 

signal (lock.control) ; 
PROCEND cobol_unlock; 



"Lock procedure for shared lock" 

PROC COBOL_SHARcD_LOCK (REF I: COBOL^LOCK)? 
LABEL START_LOOP; 
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6.1 COBOL LOCK NOTES 



START_LOOPJ loop; 

WAIT (lock.contrqd; 

IF I.hXCLUSIVE.LOCK.VALUE EQ 1 THEN 

"It not exclusively locked" 

IF I.SHAREO^COUNT = THEN 

"If unlocKed prevent exclusive lock" 
WAIT (I.EXCLUSIVE_KEY); 

IFENO; 

I.SHARED.COUNT t= I .SHARED_COUNT + i; 

SIGNAL (LOCK_CONTROL) ; 

EXIT STARTLOOP; 
ELSE 

"If exclusively locked wait until unlocked" 

signal (lock_control>; 
wait (i.shared_key) ; 
signal <i. shared key); 
ifend; 
loopend; 

PROCEND C030L_SHARFD_L0CK; 



"Lock procedure for exclusive lock" 

PROC COBOL_EXCLUSIVE_LOCK (REF ll COBOL.LOCK); 

LABEL START.LOOP; 

START_LOOPJLOOP; 

WAIT (LOCK_CONTROL); 

IF I.EXCLUSIVE^LOCK.VALUE LT 1 THEN 
"If already exclusively locked" 
SIGNAL (lock.controd; 

WAIT (I.EXCLUSIVE_LOCK) ; 
SIGNAL (I.EXCLUSIVE_LOCK); 
ELSE 

IF i.shareo_count >o then 

"If locked for shared use" 

SIGNAL (L0CK_C0NTR0L»; 

WAIT (I.EXCLUSIVE.KEY) ; 

SIGNAL (I.EXCLUSIVE_KEY) ; 
ELSE 

"If unlocked" 

WAIT (I.EXCLUSIVE.LOCK); 

"Prevent shared lock" 

PM#WAIT (I.SHARED.KEY) ; 

SIGNAL (L0CK_C0NTR0L); 

EXIT STARTLOOP; 
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ifend; 
ifend; 
loopeno; 
procend cobol_exclusi\/e_lock. 



6.2 aLtlA£tiQR£ NPI£S. 



The following excerpt by Denning(l) very licely describes 
the properties of semaphores and provides some examples of their 
uses! 

"...A semaphore is an integer variable s with an initial 
value sO > assigned on creation; associated with it is a queue 
(i» in which are placed the identifiers of processes waiting for 
the semaphore to be "unlocked." Two indivisible operations are 
defined on a semaphore st 



wait sJCs<- s - i; if 
queue Gl» enters the 
processor] 



> < the caller places himself in the 
waiting state* and releases the 



signal sl[s<- s + i; if s < remove some process from Q* and add 
it to the work queue of the processors! 

Semaphore values may not be inspected except as part of the 
wait and signal operation. If s < 0* then -s is the number of 
processes waiting in the queue Qs. Executing wait when s > 
does not delay the caller^ but executing wait when s < does* 
until another process executes a corresponding signal. Executing 
signal does not delay the caller. The programming for mutual 
exclusion using wait and signal is the same as for lock and 
unlock, with xO = 1 (wait replaces lock, and signal replaces 
unlock ).. . 



"Synchronization 

In a computation performed by cooperating processes, certain 
processes may not continue their progress until information has 
been supplied by others. In other words, although 
program-executions proceed asynchronously, there may be a 
requirement that certain program-executions be ordered in time. 



1 Third Generation Computer Systems', Peter J. 
Surveys, Vol. 3, No. k, December, 1971, pp. 



Denning, Computer 
199-201. 
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6.0 PROGRAM MANAGEMENT NOTES 
6.2 SEMAPHORE NOTES 



This is called synchronization. The precedence constraints 

existing among processes in a system express the requirement for 

synchronization. Mutual exclusion is a form of synchronization 

in the sense that one process may be blocked until a signal is 

received from another. The wait and signal operations* which can 
oe used to express all forms of synchronizations* are often 
called synchronizing primitives. 



"An interesting and important application of 
arises in conjunction with cooperating cyclic 
example made famous by Dijkstra is the "pro 
problem, an abstraction of the input/output proble 
processes* the producer and the consumer, share a 
cells, the producer places items there for late 
consumer. The producer might, for example, oe 
generates output one line at a time, and the consui 
tnat operates the line printer. The producer 
from attempting to deposit an item into a full buf 
consumer must be blocked from attempting to reno 
an empty buffer. Ignoring the details of producin 
removing, and consuming items, and concentrat 
synchronizing the two processes with respect to 
"buffer full" and "buffer empty", we arrive 
abstract description of what is required. Let a 
system action sequence for the system consisting 
and consumer processes. Let p(K) denote the numoe 
producer has deposited an item among the actions 
let c(k) denote the number of times the consumer h 
item from among the action ala2...ak. It is requi 



synchronization 
processes. An 
ducer/consume r" 
Two cycl ic 
buffer of n > 
r use by the 

a process that 
mer a process 
must be blocked 
f er , whi I e the 
ve an item from 
g, depositing, 
ing solely on 
the conditions 
t the f ol lowing 
la2. ..ak be a 
of the producer 
of times the 

ala2*. .ak, and 
as removed an 
red that 



p(k) 



c(k) < n (1) 



for all k. The programming that implements the required 
synchronization (Eq. 1) is given below? x and y are semaphores 
with initial values xO = and yO = n: 



prolproduce item; 
wait y; 
dec OS it item? 
signal x? 
goto pro; 



coniwait x; 

remove item; 
signal y; 
consume item; 
goto con; 



To prove that Eq. 1 holds for these processes, suppose 
otherwise. The either cCK) > p(k) or p(k) > c (k) +n. However, 
c{k) > p{k) is impossible since it implies that the number of 
completed wait x exceeds the number of completed signal x, thus 
contradicting xO = 0. Similarly, p (k) > c{k) + n is also 
impossible since it implies tiat the number of completed wait y 
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exceeds by more than n the number of completed signal y, thus 
contradicting yO = n. 

"Another application of synchronization is the familiar 

"read-acknowledge" form of signaling, as used in sending a 

message and waiting for a replay (B5). Define the semaphores r 
and a with initial values rO = aO = O; the programming is of the 
f orml 



IN_IdL_SLiiatE 



generate message; 
signal r; 
wait a ; 
obtain reply; 



IN THE RECEIVER 



wait r; 

obtain message, 
generate reply; 
signal a; 



synchr 
an int 
a set 
f I ipf I 
f lipf I 
respec 
off) 
senses 
attemp 
unt i I 
"inter 
Ci. B 
va I ues 
activi 



As a 
onizing pr 
errupt sys 

of pai 
op" and 
ops in 
tivel y . T 
if mi 

the occur 
ts to se 
mi = 1. T 
rupt-handl 
y regardin 
mi = 1 
ties as an 



f ina I 
imiti 
tern, 
s of 
an " 

the 
he it 

0, 
rence 
t xi 
he s 
er 
g mi 
and 

inte 



example 

ves can b 

Typical I 

f lipf lo 
interrupt 

ith p 
h interru 
and "ena 
of the i 
= i; if m 
tting of 
rocess" H 
and xi as 

xi = 
rprocess 



* I 

e use 
yt th 
PS, e 
f I i 
air 
pt is 
bled" 
th e 
i = 
xi is 
i , in 
hard 
0, w 
singa 



et 

d to 
e int 
ach p 
p f I op 
are 
said 
if m 
xcept 
the 
supp 
orde 
ware 
e ca 
I ing 



us consi 
describe t 
errupt har 
air consis 

the 
denoted b 

to be "di 
i = 1. Wh 
ional con 

setting o 

osed to a 

to act 

semaphores 

describ 

prob leml 



der how the 
he operation of 
dware contains 
ting of a "mask 
states of the 
y mi and xi, 
sabled" (masked 
en the hardware 
dition Ci, it 
f xi is delayed 
waken the ith 
n the condition 
with initial 
e the foregoing 



IN HARQWARg 

Ci occurs? wait mi; 

signal xi; 
signal mi; 
disables wait mi ; 
enable* signal mi; 

^N INTERRUPT HANDLER Hi 
start Jwait xi ; 

process interrupt; 
goto start; 
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